home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12463 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.0 KB
  1. Path: gsfc.nasa.gov!ejh
  2. From: ejh@larry.gsfc.nasa.gov (Edward Hartnett)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.object,comp.software-eng
  4. Subject: Re: Portability of code & skills (Beware of "C" Hackers etc)
  5. Date: 19 Mar 1996 21:37:45 GMT
  6. Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
  7. Message-ID: <EJH.96Mar19163745@larry.gsfc.nasa.gov>
  8. References: <4ikb6kINN1is@mayne.ugrad.cs.ubc.ca> <DoI5Ao.AyJ@assip.csasyd.oz>
  9. NNTP-Posting-Host: larry.gsfc.nasa.gov
  10. In-reply-to: donh@syd.csa.com.au's message of Tue, 19 Mar 1996 06:42:23 GMT
  11.  
  12. >>>>> "D" == Don Harrison <donh@syd.csa.com.au> writes:
  13.  
  14.     D> Kazimir Kylheku writes:
  15.     >> In article <DoG3HE.48E@assip.csasyd.oz>,
  16.     >> Don Harrison <donh@syd.csa.com.au> wrote:
  17.     >> >Graham Perkins writes:
  18.  
  19.     D> [...]
  20.  
  21.     >> >...  So if you want your new language to be a success,
  22.     >> >:then give it away for ten years, preferably with a free O.S. and all source
  23.     >> >:code as well.  It's difficult to see many other reasons for widespread 
  24.     >> >:adoption of C and Unix.
  25.  
  26.     >> >Aside from the historical argument, could another reason be that people
  27.     >> >love power and permissive languages such as C give such power? The trouble
  28.  
  29.  
  30. No I think it really was mostly because of unix.
  31.  
  32. Languages hold on a long time based on such a thing. 
  33.  
  34. As for C's supposed permissivness, I never yet saw a computer language
  35. that you couldn't write bad code in.
  36.  
  37.     >> >is, of course, that most people don't handle power responsibly because we
  38.     >> >are selfish by nature. Our short-sighted selfishness is manifested in 
  39.     >> >programming as hacking.
  40.     >> 
  41.     >> What does selfishness have to do with anything? It's just a matter of using
  42.     >> undefined and implementation defined behavior. The problem is laziness to learn
  43.     >> the language properly.
  44.  
  45.     D> I'm thinking of those who hack because they expect they won't be around to 
  46.     D> maintain their handiwork. It is selfishness because they don't care about the 
  47.     D> person maintaining it. Call it laziness, if you prefer.
  48.  
  49.     D> Those who hack knowing they are the maintainer are just fools.
  50.  
  51. No I think that's simplistic. I know of very few programmers who want
  52. to hack. But when one is starting out in a new language, etc., one can
  53. write some bad code. For example I look at my first attempts at OO
  54. programming and it looks like a bit of a hack to me now.
  55.  
  56. Not to mention that at the beginning of one's career hacking may work
  57. just fine. It takes a while for something to break usually. By the
  58. time the programmer has learned her or his lesson there are several
  59. applications that they hacked that are running in their department or
  60. whatever.
  61.  
  62. That's how hacked programming can happen in the absense of a true
  63. hacker.
  64.  
  65. Of course I have know true hackers. People who's code management is so
  66. poor, and style so cryptic, that it's impossible to work with their
  67. code. Most people are very responsive to criticism about their
  68. code. (I know I am). Some are not.
  69.  
  70. I think C definately has a culture that attracts these hackers. But
  71. they are really very rare.
  72.  
  73.     >> The C language is not as permissive as you may think: it just leaves it up to
  74.     >> the implementations to give meaning to many operations, while it perfectly
  75.     >> defines others.
  76.     >> 
  77.  
  78. Hmmm. Most of what I would call hacked code is not code that violates
  79. the standard by depending on undefined behaviour, but rather code that
  80. does weird (but usually standard conforming) things with memory or
  81. pointers.
  82.  
  83.     >> Another thing is that C compilers don't provide enough run-time checking,
  84.     >> because the standard doesn't require them to, but that's another issue
  85.     >> altogether from permissiveness inherent to the language.
  86.  
  87. Huh? gcc with the -Wall option gives me plenty of good warnings!
  88.  
  89.  
  90.  
  91.  
  92.  
  93. --
  94. Edward Hartnett                 ejh@larry.gsfc.nasa.gov
  95. * I don't speak for NASA or ARC, I just work for them! *
  96.      Goddard Distributed Active Archive Center (DAAC)
  97. Check out cool Earth Science data at: http://daac.gsfc.nasa.gov/
  98.  
  99.